Much of what the average individual experiences as work, learning or play is accomplished through their interactions with computers and software. Billions of times a day, hundreds of millions of people interact with computers and software in their daily pursuits. Increasingly, people are faced with the challenge of working with multiple independent software systems to perform everything from the most mundane to the most complicated tasks. As used herein, “software system” refers to one or more applications, programs, services, databases, firmware, executed scripts, middleware, sets of functionality available via web pages, etc. that share and/or receive data. In many cases, no single software system contains all of the required information or functionality and it is often the individual's job to act as the point of connection amongst the software systems they use.
FIG. 1 shows an example of a prior art system that illustrates how a person might interact with various software systems to complete a task. A medical practitioner uses the software systems to schedule patients, record details of the patient during the visit, and then prepare an invoice for the patient. A pair of personal computing devices used directly by the medical practitioner are in communication with a number of other computer systems.
As used herein, “personal computing device” is a computing device with which a user directly interacts. Examples of personal computing devices include smartphones, tablet computing devices, personal computers, smart thermostats, portable media players, global positioning system units, and display panels.
In this illustrated example, a first personal computing device, tablet 20a, is used by the medical practitioner to review and record medical details of the patient. The medical details are stored in a database server 24 accessed by the tablet 20a over an intranet 28. In addition, a second personal computing device, desktop computer 20b, is used by the medical practitioner to schedule patients and prepare invoices. The invoices include a calculation of the amount payable by the patient net of any amounts payable under the patient's insurance plans. In order to determine the amounts payable under the patient's insurance plans, the medical practitioner uses the desktop computer 20b to access an insurance Web portal operated by a Web portal server 32 via the Internet 36 from behind a firewall 40.
FIG. 2 shows the various software applications executing on the tablet 20a and the desktop computer 20b that the medical practitioner uses. A first software system 44a includes a patient medical database client 48 executing on the tablet 20a that is in communication with the database server 24 to access and update the data stored in a patient medical database 52 managed by the database server 24. The patient medical database client 48 is a native application for the tablet 20a that provides access to patient medical data stored in the patient medical database 52, and enables diary entries for procedures performed, medications prescribed, and observations made. The patient medical database 52 maintains data for patients across a number of medical practitioners. Each patient's patient medical data in the database 52 is associated with a patient ID.
A second software system 44b includes a clinical management application 56 for scheduling patient consultations and procedures, recording billable services and products provided to the patient, and generating invoices for patient visits for each patient and recording other accounting information. The clinical management application 56 enables entries to be made for visits, medications prescribed and provided, procedures, phone consultations, equipment provided, etc. As will be understood, some of the same entries made in the patient medical database client 48 are duplicated in the client management application 56. Patients are set up in the clinical management application 56, together with details for any insurance plans under which they have coverage, such as the name of the insurance company and the number of the insurance policy under which the patient has coverage. In addition, the corresponding patient ID from the patient medical database 52 is entered into the clinical management application 56 to enable rapid lookup of the patient's medical data via the patient's medical database client 48. Once the list of services and products provided to a patient has been entered, the gross charges are then determined for the services and products by the clinical management application 56. The amounts covered under the patient's insurance plans for each service and product can be then entered into the clinical management application 56 to enable it to generate a detailed breakdown of the net amount payable by the patient for each product or service, as well as a total.
A third software system 44c for determining the amounts payable under a patient's insurance plans includes a Web portal page 60 that is generated by the Web portal server 32 and presented on a Web browser executing on the personal computing device 20b. The Web portal page 60 includes an insurance claim portlet 64 selected from a portlet library 68 that is injected into the Web portal page 60 by the Web portal server 32. The Web portal page 60 enables the medical practitioner to select an insurance company, an insurance policy number corresponding to an insurance policy under which a patient has coverage, and a procedure, consultation or product code, and returns an amount covered by the insurance plan in question for the procedure or consultation.
FIG. 3 shows the interaction required of a user 72 with the three software systems 44a, 44b, and 44c in order to create an invoice for a patient. The lack of integration between these software systems means that the user 72 is burdened with the complex, time-consuming and error-prone job of logging into and interacting with each software system individually and trying to perform a coordinated task across them. The user 72 spends valuable time copying and pasting and re-entering information, switching between the applications and individual web pages he or she need to use, while at the same time trying to remember the information obtained from one application that needs to be entered into another.
To start, the user 72 launches the clinical management application 56 on the desktop computer 20b and views the schedule to see the scheduled list of patients for the day. When a patient is to be examined, treated, etc., the user 72 manually re-enters the patient ID from the clinical management application 56 on the desktop computer 20b into the patient medical database client 64 on the tablet 20a. The user 72 then uses the patient medical database client 48 to pull up the patient's data, review previous entries made for the patient and then register observations, procedures performed, medication prescribed, etc. When the work has been performed for a patient, the user 72 then returns to the clinical management application 56 executing on the desktop computer 20b, re-enters the information regarding the procedures performed, the consultations given, etc. Next, the user 72 enters the patient's ID, insurance policy information and the procedure/consultation codes for the work performed into the insurance claim portlet 64 on the Web portal page 60 so that the amounts payable under the patient's insurance plan(s) can be determined. This can be done using copying-and-pasting or manual entry. The amounts payable under the patient's insurance plan(s) are then entered by the user 72 into the clinical management application, again either via copying-and-pasting or manually, so that the patient-payable amount can be determined and a comprehensive invoice can be prepared for the patient by the clinical management application 56.
As can be appreciated, the amount of human interaction and potential for human error for using software systems in this manner is significant. Whether the task relates to a person trying to use the Internet to research and arrange their dream vacation, an agent in a customer services department trying to resolve an issue, a physician in an emergency ward trying to quickly access all of the information available about their patient, or a lawyer delving into various software systems to assemble a full picture of a client, the problem surfaces everywhere people use software systems during their day. The effects of the problem are universal and far-reaching, negatively affecting individual productivity, costs, quality of work and satisfaction. In aggregate, the implications are staggering and represent an untapped potential source of improvement in almost every industry.
Where two or more software systems are on separate computing devices, such as in the system of FIGS. 1 to 3, cutting and pasting or client-side integration of such software systems may not be an option. In these cases, data is generally shared by user re-entry of data from one software system into another software system, or by some manual transfer of information, such as via email or the like. This process can be cumbersome and error-prone.
One approach taken to address this type of problem is to integrate the software systems to enable data sharing between them. System integration has traditionally been done in a point-to-point fashion using programmatic connections between the server-side components of the separate systems in an invocation/response pattern. Usually, the connection is made via an application programming interface (“API”) exposed by one of the software systems to be integrated. As these APIs are typically software system-specific, knowledge of various APIs is generally required when integrating new software systems with others. Each software system generally has different identifiers for data items, thus requiring the integrator to have knowledge of the data items and structures for each software system that is to be integrated. Further, the events for each integrated software system need to make sense of the data moving between integrated software systems. These events are typically custom-designed and have to correspond with events occurring in other software systems. Examples of events include the completion of a database transaction, the appearance of a file in a directory, or the appearance of a message in a queue. Each of these events may require translating into something locally meaningful for each integrated software system.
Integration systems have been developed to handle the integration between different software systems, but these integration systems can encounter all the same issues as when directly integrating software systems.
In some cases, the use of an integration server is not feasible as a cost-efficient solution for integrating software systems.
Turning back to the software systems of FIGS. 2 and 3, as will be readily understood, there isn't a feasible manner in which an integration server could be used to reduce the manual interaction of a user in order to complete a task. The patient medical database 52 maintains patient medical data that is confidential and is not directly cross-relatable to the information maintained by the Web portal server 32. As a result, there is no easy way to integrate these two resources. The data held within the clinical management application 56 is stored on the desktop computer 20b and is thus not readily integrated with the patient medical database 52 nor with the Web portal server 32. Theoretically, the clinical management application 56 could be customized to retrieve insurance information from various insurance portals, but it would have to be updated whenever there is a change in the location or format of this information for any of the insurance portals.
Server-side integration becomes even more challenging with so many widely-separated software systems coming together only on a computing device being used by an end-user and, often, on an ad-hoc basis. Predicting the software systems that a single user, let alone multiple users, may wish to interact with to complete a task is highly challenging. The integration of all of the servers for each of these software systems is still more cumbersome. Even where server-side integration has been performed for two servers, user authentication may be very onerous. The user has to log in to a first server with a first set of login credentials and then have the first server use a system account to access resources and/or functionality available via a second server. The second server would have to extend a broad range of trust to a system account and won't know at all on whose behalf the first server is acting during a particular transaction. Thus, server-side integrations are high-cost solutions that can be inappropriate for such ad-hoc pairings of software systems by users.
Point-to-point integrations can work acceptably for small numbers of software systems with relatively simple data to be shared. Due to the complexity of such integrations, they are generally reserved for enterprise systems. As the interaction of each software system with each other software system is explicitly programmed, the integration of each additional software system requires significantly-increased effort. Another issue is that it is generally very difficult for a third party to enhance the integration between software systems.
There are issues with integrating software systems on the personal computing device. In some circumstances, personal computing devices (i.e., those with which an end user directly interacts) upon which such software systems operate may have processing power that is constrained. It can, however, be desirable to have software systems interact with components, services and/or databases that are located on remote computer systems. In some scenarios, there can be latency issues or relatively high data transmission costs associated with the connections to such remote computer systems. Further, communicating all of the data from a database required to generate a user interface can increase the security risk level. Communications between the personal computing device and resources such as database servers can be hindered by firewalls. Still further, if the personal computing device undergoes a system failure, all of the data would be lost if the software systems are integrated client-side. As a result, it can be undesirable to have integration occur on the computing device.
Yet another issue is that data persistence is not handled very well in most integrations. During the processing of a transaction, if a software system responsible for performing a task is not present, generally the transaction will fail. In order to instill robustness into such integrated software systems, event-handling and/or message queuing has to be added as fail-safes for various scenarios, adding further to the complexity of such integrations.
One solution proposed, and deprecated, for data sharing by Google can be found at http://code.google.com/apis/gadgets/docs/pubsub.html. The proposal describes a publish-subscribe framework to pass messages from one gadget to another. Google gadgets are canned sets of functionality that can be included in a web portal, such as iGoogle. Google previously supported this functionality which would not be present in other portals. Gadgets with data to share would publish the data using a set of defined identifiers via channels, as long as the gadgets were aware that at least one other gadget was interested in the data. Gadgets interested in the data would declare their interest in knowing when the values of those data items have changed. As the data is pushed via channels at the time there is a change, however, the state of the data may be unavailable to new gadgets. Further, gadgets have to have been programmed with knowledge of the defined data identifiers. This solution is specific to Google gadgets and is not portable to other types of software systems.
It is therefore an object of the invention to provide a novel method and system for enabling data sharing between software systems.